前端在边缘：深入探讨 Cloudflare Workers 和 AWS Lambda@Edge

在对更快、更安全、更高度个性化用户体验的不懈追求中，Web 的架构正在经历一场深刻的变革。多年来，模型很简单：一个中心化的服务器，一个用于缓存静态资源的内容分发网络（CDN），以及一个客户端。但随着应用程序的复杂性不断增加，以及用户对即时交互的期望日益强烈，这种传统模型正显示出其局限性。欢迎来到边缘计算时代——这是一个范式转变，它将计算和逻辑从遥远的云服务器转移到网络边缘，距离最终用户仅有几毫秒之遥。

对于前端开发者和架构师来说，这不仅仅是另一个后端趋势。它代表了我们构建、部署和交付 Web 应用程序方式的根本性变化。它赋予了前端以前只有服务器才拥有的能力，模糊了界限，释放了前所未有的潜力。在这个全球舞台上，两大巨头已成为领跑者：Cloudflare Workers 和 AWS Lambda@Edge。本指南将对这两个平台进行全面探索，帮助您理解它们的核心原则，比较它们的优缺点，并决定哪个更适合您的下一个全球项目。

什么是前端边缘计算？从 CDN 到可编程边缘

要理解边缘计算的重要性，首先必须了解它的演变。其核心，“边缘”指的是位于您的应用程序源服务器和用户之间的全球服务器网络（存在点，或 PoPs）。传统上，这些服务器被 CDN 用于一个主要目的：缓存。

演变：超越缓存

CDN 通过将图片、CSS 和 JavaScript 文件等静态资源的副本存储在全球各地的 PoPs 中，彻底改变了 Web 性能。当东京的用户请求一个文件时，该文件会从日本附近的服务器提供，而不是长途跋涉、高延迟地访问位于北美的源服务器。这极大地减少了加载时间。

然而，这种模型仅限于静态内容。任何动态逻辑——比如个性化内容、验证用户或执行 A/B 测试——仍然需要往返源服务器。这次往返带来了延迟，这是良好用户体验的死敌。

边缘计算打破了这一限制。它使 CDN 的边缘网络变得可编程。开发者现在可以直接在这些边缘服务器上部署和执行自定义代码，而不仅仅是缓存静态文件。这意味着动态逻辑可以在离用户最近的 PoP 中运行，即时拦截请求和修改响应，对于许多任务来说，完全无需联系源服务器。

为什么它对前端很重要？

将逻辑带到边缘对前端开发和应用程序性能产生了巨大影响。其好处是巨大的：

• 大幅降低延迟：通过在更靠近用户的地方执行代码，您消除了到中心化服务器的往返时间。这带来了更快的 API 响应、更快的页面加载以及更灵敏、响应更快的用户界面。
• 增强性能：像 A/B 测试、功能开关和路由等任务可以在边缘处理。这减轻了客户端浏览器和源服务器的负担，从而全面提升了性能。
• 默认实现全球可扩展性：边缘函数部署在提供商的整个全球网络中。您的应用程序会自动扩展并具有弹性，无需任何手动干预即可处理来自世界任何地方的流量高峰。
• 提高安全性：您可以在请求到达您的源基础设施之前，在边缘处理与安全相关的任务，例如验证令牌（如 JWT）、阻止恶意请求或强制执行访问控制。这创建了一个强大的、分布式的安全边界。
• 成本效益：从源服务器卸载请求可以显著减少其负载，从而降低基础设施成本。此外，边缘平台的无服务器定价模型通常非常具有成本效益。
• 强大的个性化：您可以修改 HTML，根据地理位置或用户 cookie 个性化内容，并为不同的用户群体提供不同的体验——所有这些都具有最小的延迟。

Cloudflare Workers：V8 Isolate 的革命

Cloudflare 作为 CDN 和安全领域的长期领导者，推出了 Cloudflare Workers，成为无服务器边缘计算领域的先驱平台。其核心创新不仅在于代码运行的位置，还在于代码如何运行。

什么是 Cloudflare Workers？

Cloudflare Workers 允许您在 Cloudflare 庞大的全球网络上运行 JavaScript 和 WebAssembly (Wasm)，该网络覆盖了 100 多个国家的数百个城市。Worker 本质上是一段拦截和处理 HTTP 请求的代码。它可以在请求到达您的源服务器之前修改请求，直接从边缘生成响应，或从多个来源流式传输内容。

其开发者体验旨在让人感到熟悉，使用了类似 Service Worker 的 API。如果您曾经为 Web 浏览器编写过 service worker，那么这个编程模型会感觉非常直观。

V8 Isolates 的魔力

Cloudflare Workers 性能背后的真正天才之处在于它使用了 V8 Isolates，而不是传统的容器或虚拟机（VMs）。V8 是驱动 Google Chrome 和 Node.js 的同一个高性能 JavaScript 引擎。

一个 Isolate 是一个轻量级的上下文，它将变量与操作这些变量的代码组合在一起。多个 Isolates 可以在单个操作系统进程中运行，但它们之间是完全隔离的。这带来了深远的影响：

• 接近于零的冷启动：一个新的 Isolate 可以在 5 毫秒内启动。这比启动一个传统无服务器函数的容器可能需要的几秒钟要快几个数量级。对用户来说，这意味着冷启动几乎不存在，每个请求都很快。
• 巨大的可扩展性和效率：Isolates 非常轻量，消耗的内存远少于容器。这使得 Cloudflare 可以在一台物理机器上运行数千个 Worker 脚本，使该平台高效且成本效益高。
• 增强的安全性：V8 Isolates 的沙盒特性提供了强大的安全边界，防止一个 Worker 影响另一个。

实用案例与代码示例

Cloudflare Workers 的功能非常丰富。让我们来探讨一些常见的用例。

在边缘进行 A/B 测试

您可以将用户路由到您网站的不同版本，而无需任何客户端 JavaScript 闪烁或复杂的后端逻辑。Worker 会检查传入的 cookie 并重写 URL，以从不同的源或路径获取内容。

            
// Example: A/B Testing Worker

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const AB_COOKIE = 'ab-test-variant'
  const cookie = request.headers.get('cookie')

  // Determine which variant to show
  let group = 'control'
  if (cookie && cookie.includes(`${AB_COOKIE}=treatment`)) {
    group = 'treatment'
  }

  let url = new URL(request.url)

  // If the user is in the treatment group, fetch the alternative page
  if (group === 'treatment') {
    url.pathname = '/treatment' + url.pathname
  }

  // Fetch the appropriate version
  return fetch(url, request)
}

            

              
                Copy
              
            
          

动态 URL 重写和重定向

为用户维护简洁的 URL，同时将它们映射到不同的后端结构，或在网站迁移后执行对 SEO 友好的重定向。

            
// Example: Dynamic Redirect Worker

const redirectMap = new Map([
  ['/old-about-us', '/about'],
  ['/products/old-product', '/products/new-product']
])

addEventListener('fetch', event => {
  const url = new URL(event.request.url)
  const { pathname } = url

  const destinationURL = redirectMap.get(pathname)

  if (destinationURL) {
    return Response.redirect(url.origin + destinationURL, 301)
  }

  // No redirect needed, proceed as normal
  return fetch(event.request)
})

            

              
                Copy
              
            
          

在边缘进行身份验证和授权

通过在边缘验证 JSON Web Token (JWT) 来保护您的整个应用程序或特定路由。无效的请求在消耗源服务器资源之前就会被拒绝。

            
// Conceptual Example: JWT Validation Worker
// Note: This requires a JWT library compatible with Workers

import { verify } from 'jwt-library'; // Placeholder for a real library

const JWT_SECRET = 'your-super-secret-key';

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const authHeader = request.headers.get('Authorization')

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return new Response('Unauthorized', { status: 401 })
  }

  const token = authHeader.substring(7)

  try {
    // Verify the token at the edge
    await verify(token, JWT_SECRET)
    // If valid, proxy the request to the origin
    return fetch(request)
  } catch (error) {
    // If invalid, reject the request
    return new Response('Invalid token', { status: 403 })
  }
}

            

              
                Copy
              
            
          

AWS Lambda@Edge：用无服务器能力扩展 CloudFront

亚马逊网络服务（AWS）为其边缘计算提供了强大的解决方案：Lambda@Edge。它不是一个独立的产品，而是其全球 CDN 服务 Amazon CloudFront 的一项功能。Lambda@Edge 允许您响应 CloudFront 事件来运行 AWS Lambda 函数，将 AWS 生态系统的强大功能和熟悉度带到边缘。

什么是 Lambda@Edge？

Lambda@Edge 让您可以在全球的 AWS 边缘站点运行 Node.js 和 Python 代码。这些函数不是由 API Gateway 或 S3 事件触发，而是由请求通过 CloudFront 的生命周期触发。这种紧密的集成既是它最大的优势，也是与 Cloudflare Workers 的一个关键区别点。

与在每个 PoP 上运行的 Cloudflare Workers 不同，Lambda@Edge 函数部署到 AWS 的区域性边缘缓存，这是一个比 CloudFront PoPs 全集更小、更集中的位置集合。这是一个具有性能影响的关键架构差异。

理解四种事件触发器

Lambda@Edge 的功能由四种不同的事件触发器定义，您可以将函数附加到这些触发器上。理解这些是有效使用该服务的关键。

• 查看器请求 (Viewer Request)：此触发器在 CloudFront 从查看器（用户）接收到请求后，但在检查其缓存之前触发。它非常适合需要在每个请求上都执行的任务，如重定向、标头操作或基于 cookie 的个性化。
• 源请求 (Origin Request)：此触发器仅在请求的内容不在 CloudFront 缓存中（缓存未命中）时触发。该函数在 CloudFront 将请求转发到您的源服务器（例如 S3 存储桶或 EC2 实例）之前执行。它非常适合复杂的 URL 重写、动态源选择或添加只有源服务器需要看到的身份验证标头。
• 源响应 (Origin Response)：此触发器在 CloudFront 从源服务器收到响应后，但在缓存该响应之前触发。您可以用它来修改来自源的响应，例如添加安全标头、调整图像大小或隐藏源特定的标头。
• 查看器响应 (Viewer Response)：此触发器在 CloudFront 将最终响应发送回查看器之前触发，无论它是缓存命中还是未命中。它对于添加浏览器需要的标头（如 CORS 或 HSTS 标头）或记录最终响应数据很有用。

实用案例与代码示例

让我们看看如何使用 Lambda@Edge 的基于触发器的模型来解决常见问题。

为安全和缓存自定义标头

使用查看器响应 (Viewer Response) 触发器，为提供给用户的每个响应添加重要的安全标头，如 `Strict-Transport-Security`。

            
// Example: Add Security Headers (Viewer Response)

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;
    const headers = response.headers;

    headers['strict-transport-security'] = [{ key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' }];
    headers['x-content-type-options'] = [{ key: 'X-Content-Type-Options', value: 'nosniff' }];
    headers['x-frame-options'] = [{ key: 'X-Frame-Options', value: 'DENY' }];
    headers['x-xss-protection'] = [{ key: 'X-XSS-Protection', value: '1; mode=block' }];

    callback(null, response);
};

            

              
                Copy
              
            
          

针对特定设备的内容交付

使用查看器请求 (Viewer Request) 触发器，您可以检查 `User-Agent` 标头，将移动用户重定向到专用的移动网站，或重写 URL 以获取移动优化的内容版本。

            
// Example: Mobile Redirect (Viewer Request)

'use strict';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;
    const headers = request.headers;

    const userAgent = headers['user-agent'] ? headers['user-agent'][0].value : '';
    const isMobile = userAgent.includes('Mobile') || userAgent.includes('Android');

    if (isMobile) {
        const response = {
            status: '302',
            statusDescription: 'Found',
            headers: {
                'location': [{ key: 'Location', value: 'https://m.yourwebsite.com' + request.uri }]
            }
        };
        callback(null, response);
        return;
    }

    // Continue with the original request for non-mobile users
    callback(null, request);
};

            

              
                Copy
              
            
          

通过访问控制保护您的源服务器

通过源请求 (Origin Request) 触发器，您可以在将请求转发到源服务器之前注入一个秘密标头。然后，您的源服务器可以配置为只接受包含此秘密标头的请求，从而防止任何人绕过 CloudFront。

            
// Example: Adding a Secret Header to Origin Requests (Origin Request)

'use strict';

const SECRET_HEADER_VALUE = 'your-very-secret-value';

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    // Add a secret header
    request.headers['x-origin-secret'] = [{ key: 'X-Origin-Secret', value: SECRET_HEADER_VALUE }];

    // Forward the modified request to the origin
    callback(null, request);
};

            

              
                Copy
              
            
          

正面交锋：Cloudflare Workers vs. AWS Lambda@Edge

这两个平台都非常强大，但它们建立在不同的理念和架构之上。在它们之间做出选择需要仔细比较它们的主要特性。

比较的关键要点：

• 在原始性能和最低延迟方面，Cloudflare Workers 凭借其 V8 Isolate 架构和庞大的 PoPs 网络占据优势。没有冷启动对于面向用户的应用程序来说是一个显著的优势。
• 对于与现有 AWS 技术栈的深度集成，Lambda@Edge 是自然的选择。它利用了熟悉的 AWS 概念，如 IAM，并与 CloudFront、S3 和其他服务无缝集成。
• 开发者体验常被认为是 Cloudflare Workers 的一个主要优势。Wrangler CLI、快速部署和简单的 API 使得开发周期非常迅速。Lambda@Edge 涉及更多的配置和更慢的部署时间。
• Lambda@Edge 通过其四种不同的触发器提供了更精细的控制，允许您通过仅在绝对必要时（例如，仅在缓存未命中时）运行代码来优化成本和性能。

边缘的未来：下一步是什么？

前端边缘计算仍处于早期阶段，创新正以惊人的速度发生。最初对无状态计算的关注正在迅速扩展。以下是一些塑造未来的趋势：

• 边缘状态：最大的前沿是管理状态。像 Cloudflare Workers KV 和 Durable Objects 这样的服务正在开创在边缘存储数据的方法，使更复杂的应用程序，如实时聊天、协作文档和购物车，能够完全在边缘网络上运行。
• WebAssembly (Wasm)：Wasm 允许开发者在安全的沙盒中以接近本机的速度运行用 Rust、C++ 和 Go 等语言编写的代码。这为在边缘执行性能关键型任务，如视频处理、复杂计算和机器学习推理，打开了大门。
• 边缘数据库：在全球网络中复制和同步数据是一项巨大的挑战。像 Cloudflare 的 D1 和 FaunaDB 这样的新服务正在构建全球分布式的数据库，旨在与边缘函数无缝协作，最大限度地减少数据访问延迟。
• 边缘 AI/ML：随着设备和边缘服务器变得越来越强大，在边缘运行机器学习模型以执行个性化、欺诈检测和图像分析等任务将变得司空见惯，以最小的延迟提供智能响应。

为您的项目做出正确选择

在 Cloudflare Workers 和 AWS Lambda@Edge 之间的选择在很大程度上取决于您的具体需求、现有基础设施和性能目标。

何时选择 Cloudflare Workers

• 性能是您的首要任务。如果您正在构建一个高度互动的应用程序，其中每一毫秒的延迟都很重要，那么 Workers 接近于零的冷启动是一个决定性的优势。
• 您的逻辑是无状态的，或者可以使用边缘原生状态。Workers 在身份验证、A/B 测试和重定向等任务上表现出色。对于状态，您将使用它们的生态系统（KV、Durable Objects）。
• 您重视快速、现代的开发者体验。如果您的团队希望通过简单的 CLI、快速的部署和 Web 标准 API 快速行动，Workers 是一个绝佳的选择。
• 您正在构建一个新项目或不依赖于 AWS 生态系统。它为构建全球分布式应用程序提供了一个强大的、自成一体的平台。

何时选择 AWS Lambda@Edge

• 您已深度投入 AWS 生态系统。如果您的基础设施、数据存储和 CI/CD 管道已经建立在 AWS 之上，Lambda@Edge 将更自然地集成。
• 您需要对请求生命周期进行精细控制。四种触发器模型允许进行微调的逻辑，可以根据缓存状态优化成本和执行。
• 您的团队已经精通 AWS Lambda 和 IAM。学习曲线将会平缓得多，因为它建立在现有知识之上。
• 您的边缘逻辑需要 Node.js 特定的模块或更复杂的计算，这可能会超过 Cloudflare Workers 更严格的 CPU 限制。

结论：拥抱前端边缘

前端边缘计算不再是一项小众技术；它是高性能 Web 应用程序的未来。通过将逻辑从中心化服务器转移到全球分布式网络，我们可以构建比以往任何时候都更快、更安全、更具弹性的体验。Cloudflare Workers 和 AWS Lambda@Edge 是引领这一潮流的两个杰出平台，各自拥有独特的架构理念和鲜明的优势。

Cloudflare Workers 以其原始速度、创新的 V8 Isolate 架构和卓越的开发者体验令人眼花缭乱，使其成为对延迟要求极高的应用程序的绝佳选择。AWS Lambda@Edge 则利用了 AWS 生态系统的巨大力量和广度，为那些已经投入其平台的用户提供了无与伦比的集成和精细控制。

作为开发者或架构师，了解边缘的能力现在是一项关键技能。它解锁了解决长期存在的性能瓶颈和构建一类全新的、真正全球化的、即时响应的应用程序的能力。边缘不仅仅是部署代码的新位置——它是一种为 Web 构建的新思维方式。